Example for Message Queue Sniffer

This topic provides an example for the Message Queue Sniffer.

Let us assume that the JMS provider is Sun Microsystems and the JMS Administrator has created the following administered objects of type Queue with lookup names and stored them in a file system with path C:\Bindings:

• MDMQueue
• MDMQueueConnectionFactory

Configuring the JNDI Parameters tab

To locate and access these administered objects, the user must provide values for the necessary Java Naming Directory Interface (JNDI) parameters like Class Name and Provider URL. The repository is a file system and hence, the corresponding values for Class Name and URL are:

The following table lists the Repository name and its respective Class name used by JNDI to locate the resources:

Provide the optional authentication details, if necessary.

Configuring the Receiver Details tab

Specify the values for the Queue Type in the Receiver details tab:

Message Processing Area Message Processing is a mechanism to handle the incoming messages from the JMS server and perform the necessary event and business object translation. The following are the types of incoming messages that a JMS provider supports:

• TextMessage
• ByteMessage
• MapMessage
• ObjectMessage
• StreamMessage

However, the input to the sniffer must be an XML associated with a database action like insert, update, or delete. So, once a client receives a message from a JMS server, some extra processing must be performed to convert that message in to a format expected by the sniffer. There are two types of Message processing - Default and Custom.

Default
In default MDM processing the following are the assumptions:

• Incoming message is a TextMessage
• Its payload contains XML in text format
• Database specific events like insert, update, and delete are specified in the TextMessage application properties like (key, value) pair in which the value of the Event Name is the key and the value of insert, update, or delete is the value

Therefore, the key name is database_action and its value can be new/new_old/old.

Custom
If the user wants to perform a different kind of business object or event translation other than the default MDM process then the user can provide a custom class which does the necessary business object and event translation. This custom class must implementcom.cordys.rcor.publisher.sniffer.messaging.IMessageHandler interface. Therefore, the MapMessageHandler is the custom class given in the class name of the custom process.